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© Method and system for certificate based alias detection. 



© A distributed computer system employs certif- 
icate based alias detection to ensure a policy of 
separation of duties. Biometric information is col- 
lected during computer user account creation that is 
converted to canonical form and digitized. This 
digitized canonical form, along with account data and 



authentication data, is included in the user's account 
information. Authorization to execute any task is vali- 
dated at the time a request is made by comparison 
of the digitized canonical forms of biometric data of 
the user completing the request with those of the 
user initiating the request. 
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BACKGROUND OF THE INVENTION 

This invention relates to computer systems, 
and more particularly to a system for detecting 
computer user account aliases. 

As it is known in the art, effective computer 
operating system security measures help prevent 
unauthorized access to and theft of proprietary 
software, software plans, and computer time. These 
measures can also protect equipment, software, 
and computer files from damage caused by tam- 
pering. The source of a security breach on a com- 
puter system can usually be traced to one of three 
categories: user irresponsibility, user probing, or 
user penetration. 

User irresponsibility usually refers to situations 
where an authorized user purposely or accidently 
causes some noticeable damage. An example 
would be a computer user who is authorized to 
access certain computer files, makes an authorized 
copy of a key file to improperly transfer. This type 
of breach can be characterized as a breach of 
trust. There is little that a computer operating sys- 
tem can do to protect sites from this source of 
security failure, since the initial access to the file 
was completely authorized, and the breach oc- 
curred by the improper transfer of the fruits of the 
authorized access. 

User probing refers to situations where a com- 
puter user obtains unauthorized access by exploit- 
ing insufficiently protected parts of the computer 
system. Probing typically reflects an exploration of 
top-level facilities to which a computer user has 
legitimate access to browse through the computer 
system. 

User penetration refers to an attempt to bypass 
existing security controls by finding relatively ob- 
scure flaws in their implementation. 

To guard against user probing and user pene- 
tration, computer systems typically include pro- 
cesses to authenticate the identity of a user. Au- 
thentication of a user identity in a computer system 
is the verification of a user's identity so that secu- 
rity policies can properly be applied to requests 
from that user. Authentication typically involves the 
examination of an individual's credentials, such as 
biometric information, encryptographic information, 
and so forth. 

In medium- to large-scale distributed computer 
systems, it is often the case that a given computer 
user may well have access to the computer net- 
work via several different computer user accounts, 
each individually legitimate. For example, a com- 
puter user might have access to the computer 
across the network via an employee's computer 
system in the work place, and via a personal com- 
puter with a modem at home. Where separation of 
duties or similar policies are to be enforced by a 



computer network server, techniques should exist 
for the computer network server to determine 
whether or not two different computer requests are 
from distinct or different individuals. Where one 

5 individual can access two or more user accounts 
those accounts are known as alias accounts of that 
one individual. 

An alias, therefore, is defined as an alternate 
identity for any individual who is held accountable 

m for his/her actions. Where the possibility of alias 
computer user accounts exists, the straightforward 
comparison of authentication data, e.g., passwords, 
public keys, etc., is insufficient to prevent unwanted 
aliasing of a user, simply because there are typi- 

75 cally no controls in effect to prevent one user from 
obtaining distinct user accounts containing poten- 
tially distinct authentication information. 

One type of computer security required in 
many business and commercial applications has 

20 come to be called a policy for the separation of 
duties. This policy requires that for critical business 
procedures certain steps of that business proce- 
dure must be performed by different individuals. 
The purpose of this policy is to distribute respon- 

25 sibility for a transaction among several different 
people so that no one person, acting alone, can 
cause the action in question to occur. The pre- 
sumption is that distinct or different individuals 
having different responsibilities will act as checks 

30 on each other. 

An example of a policy for the separation of 
duties which may be encountered in every day life 
would be a personal safety deposit box. A bank 
usually requires that a bank employee and the 

35 safety deposit owner use two distinct keys and to 
both sign a log book in order for the safety deposit 
box owner to gain access to the safety deposit box. 
Requiring two keys is referred to as access control. 
Requiring both individuals to sign a log is referred 

40 to as audit control. The bank policy is that the 
owner and bank employee must be two distinct or 
different individuals. Another example would be 
when a business employee hands in an expense 
form and would like to be issued a company check 

45 for those expenses. Corporate policy would require 
that the expense check may not be signed and 
authorized by the same person. These two exam- 
ples illustrate that the principle of separation of 
duties is widely required for manual systems. 

so Several approaches have been advanced in the 
past for enforcing separation of duties policies. The 
most common approach for enforcement of separa- 
tion of duties in automated computer systems has 
been for the security administrator to define distinct 

55 groups or roles and to manually ensure that the 
assignment of the individuals to critical groups or 
roles does not overlap. One problem with this ap- 
proach is that it does not prevent a threat from a 
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given individual who may have access to a com- 
puter system from two distinct accounts. 

Known approaches to the authentication and 
identification of users by user account have gen- 
erally presupposed that user account aliasing is 
prevented by the use of operational or procedural 
rules. Approaches for enforcing a separation of 
duties policy have assumed that aliasing does not 
occur, and that authenticatible user account iden- 
tities are therefore sufficient to identify individuals 
as well. The problem with this approach is that the 
premise that alias accounts do not exist particularly 
in large computer systems is generally incorrect. 
Moreover, preventing account aliasing becomes 
more and more impracticable as networks grow 
larger and larger because even if identifying in- 
formation unique to an individual, such as biometric 
information, is obtained when a new account is 
created, in order to associate that new user ac- 
count with any other user account that may exist 
for that individual on the network, an exhaustive 
search over every user account already in the 
system would have to be performed. Such a 
search is costly even for relatively small computer 
networks, and is effectively impossible for large 
computer networks. 

One further type of user authentication uses 
biometric reader information which is fed to the 
computer system during login. Biometric informa- 
tion is provided from a biometric reader at each 
login point or station. A biometric reader can typi- 
cally detect unique information or characteristics of 
an individual such as eye scans, thumbprints, DNA 
sampling, and so forth. While the use of biometric 
information for purposes of user authentication is 
often performed it is generally expensive because 
biometric readers are needed at every login point. 
In addition, if biometric information is ever dis- 
closed there is no way to undo the damage. For 
these reasons, continued use of encryptographic 
information such as passwords and/or smart cards 
have usually been indicated as a better alternative 
for authentication than biometrics. 

SUMMARY OF THE INVENTION 

The invention in its broad form resides in a 
method of performing alias detection on a com- 
puter system as in claim 1. The invention also 
resides in a system for alias detection as in claim 
8. 

Described herein is a method of performing 
alias detection on a computer system, which in- 
cludes the steps of storing in respective user ac- 
counts identification information uniquely character- 
izing each of a plurality of computer users, initiat- 
ing execution of a computer system resource upon 
a first request from a first user account, processing 



a second request for execution using a user ac- 
count, comparing said identification information 
stored in said user account used during said sec- 
ond request with said identification information in 

5 said first user account, and determining whether 
said first user account and said user account used 
in said second request are aliases. With such an 
arrangement an alias detection technique that is 
performed at the time of execution of a computer 

to resource using a second request for user account 
information is provided. Such a technique can be 
used for example to control access to restricted 
computer resources, monitor and control the exis- 
tence of alias accounts on the computer system, 

75 and implement a separation of duties policy on 
resources of the computer system. 

In a modification described hereinafter, a meth- 
od of operating a distributed computer system in- 
cludes the steps of storing in respective user ac- 

20 counts identification information uniquely character- 
izing each of a plurality of computer users, storing 
a list of selected user accounts in an authorization 
store, initiating execution of a computer system 
resources access program upon request from a 

25 user account, and processing the request from the 
user account to authorize access to a plurality of 
computer system resources by comparing the 
identification information stored in the user account 
and in the list of authorized user accounts, and 

30 determining whether the user account is an alias of 
any of the list of authorized user accounts. With 
such an arrangement, alias detection is determined 
at the time that a user attempts to gain access to a 
computer system resource. 

35 In a further modification described hereinafter, 
a method of operating a distributed computer sys- 
tem includes the steps of storing in respective user 
accounts identification information uniquely char- 
acterizing each of a plurality of computer users, 

40 and initiating execution of a stage of a selected 
transaction program having a plurality of stages 
upon request from a first user account. The method 
further comprises the steps of processing a request 
from a second user account to authorize execution 

45 of a subsequent stage of the selected transaction 
program by comparing the identification information 
stored in the first user account and in the second 
user account, and determining whether the second 
user account is an alias of the first user account. 

so With such an arrangement, alias detection is deter- 
mined at the time that a subsequent user attempts 
to complete the selected transaction. By not as- 
suming that login authentication also uniquely iden- 
tifies a user, who may, in fact, have alias accounts, 

55 this arrangement provides for detection of aliases 
at the point of policy application without ever re- 
quiring an exhaustive search throughout the net- 
work for potentially aliased accounts. The present 
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invention does not assume that user account al- 
iasing is prevented. Rather, it assumes that alias 
accounts may be freely created, and uses data that 
uniquely identifies the owner of each account to 
detect the existence of unwanted aliasing at the 
point in time just before execution of a protected 
activity is to commence. 

Also described herein is a system of operating 
a distributed computer system to implement alias 
detection is provided, including storing in respec- 
tive user accounts, digitally-signed account certif- 
icates including identification information uniquely 
characterizing each of a plurality of computer us- 
ers, initiating execution of one stage of a selected 
transaction program having a plurality of stages 
from a store of application programs on the com- 
puter system upon request from a first user ac- 
count, processing a request from a second user 
account to authorize execution of a subsequent 
stage of the selected transaction program by com- 
paring the identification information included in ac- 
count certificates stored in the first user account 
and in the second user account, determining 
whether the second user account is an alias of the 
first user account, and allowing the processing re- 
quest to execute the subsequent stage of the se- 
lected transaction program if the second user ac- 
count is not an alias of the first user account. With 
such an arrangement a computer security system 
which uses a combination of biometric and cryp- 
tographic techniques is provided. Specifically it 
provides a system for supporting a separation of 
duties policy that is not dependent on a single 
authority for registering accounts, or rigorous ac- 
count administration to segregate accounts into dif- 
ferent non-overlapping groups or roles (i.e., static 
enforcement of separation of duties), or preventing 
multiple accounts for an individual. Such a system 
embodying the invention can support dynamic en- 
forcement of separation of duties by allowing an 
individual to assume multiple roles if need be, and 
ensure that within the context of a given business 
function, the individual has not assumed conflicting 
roles. It achieves this by the use of digitized bio- 
metric data or other uniquely identifying data to 
determine if different accounts are used by a single 
individual, i.e., are aliases of each other. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more detailed understanding of the invention 
may be had from the following description of pre- 
ferred embodiments, given by way of example and 
to be understood in conjunction with the accom- 
panying drawing wherein: 

Figure 1 is a diagram in block form of a distrib- 
uted computer system which may be used to 
implement certificate-based alias detection ac- 



cording to one embodiment of the invention; 
Figure 2 is a diagram in block form of how an 
account certificate incorporating certificate-alias 
detection data is created; 
5 Figure 3 is a diagram in block form of how 
certificate-based alias detection is utilized here- 

Figure 4 is a diagram in block form of an exam- 
ple system incorporating certificate-based alias 
w detection. 

DESCRIPTION OF THE PREFERRED EMBODI- 
MENTS 

is Referring now to Figure 1 , a computer system 

10 is depicted with access available to individual 
users 10a-10c. Each individual user 10a-10c has a 
workstation 12a-12c connected to a local area net- 
work 14. The workstations 12a-12c provide each 

20 individual user 10a-10c access to a set of applica- 
tions to perform his/her duties. The applications 
reside on an application server system 16 con- 
nected to the local area network 14. 

The application server system 16 is a com- 

25 puter system which contains a set of application 
programs (hereinafter "applications") that can also 
be accessed by other computer users (not shown) 
via the local area network 14. Each individual user 
10a-10c is identified by one or more accounts 

30 maintained in a name service program 19 on a 
name server system 18. 

The name server system 18 is a computer 
system containing name service software 19 and 
accessed by any computer user via the local area 

35 network 14. The name service software 19 allows 
the names of network applications, systems, and 
other network-accessible objects to be independent 
of their physical location in the iocai area network 
14. For example, a unique name will be stored in 

40 the name service program 19 on the name server 
system 18 to allow individual users 10a-10c to 
execute a unique application on an application 
server system 16. 

In the name server system 18, each individual 

45 user 10a-10c will have a personal account, and one 
or more "special" accounts; each account, whether 
personal or special, has a respective account iden- 
tification to enable each individual user 10a-10c to 
log on to the computer system 10 to use a particu- 

50 lar application identified in the name server system 
18. Each "special account" corresponds to a spe- 
cific job function, e.g., organizational role. An in- 
dividual user logged in under such a specialized 
account is able to perform those applications par- 

55 ticular to the corresponding job function. 

Referring now to Figure 2, an applicant 100 
supplies biometric information 105 to a registrar 
110 as part of the processing of an account. All 
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accounts in the computer system 10 are admin- 
istered by the account registrar 110, an entity hav- 
ing its own identity, with responsibility for account 
administration for some enterprise. During the pro- 
duction or modification of an account, the registrar 
110 captures an applicant's 100 biometric informa- 
tion 105. Here the system uses a public key en- 
cryption technology for authentication to provide 
authentication data. The authentication data that will 
be associated with the account for use in login 
authentication is the public key of a public 
key/private key pair. The registrar 110 causes a 
new public/private key pair to be generated. The 
private key is issued to the user (typically in the 
form of stored information in some device such as 
a passcard) while the public key for the account is 
stored along with other account information in a so- 
called "certificate" for that account. The biometric 
data 105 supplied by the applicant 100 is prefer- 
ably integrity locked into the certificate along with 
the authentication data (e.g. user's public key) and 
other security-critical information which may be 
needed by the system (e.g. such as the user's 
authorized role). The integrity-locked digitized ca- 
nonical biometric data hereinafter referred to as 
"certificate-based alias detection data (CBAD)." 
The registrar integrity locks the certificate by ap- 
pending a digital signature to it. A digital signature 
in its simplest form is simply an encrypted copy of 
the certificate that is encrypted using the registrar's 
110 assigned private key (which is known only to 
the registrar 110 and the registrar's work station). 
The digital signature is used with the data to be 
"integrity-locked" by using the signature to provide 
an encryptographic checksum or other appropriate 
code. Appending the digital signature provides "in- 
tegrity-locked" or digitally signed ac- 
count/authentication/certificate-basedalias detection 
data 120 where it is stored in the name service 
program 19. The above mentioned public key cryp- 
tographic type techniques are used to ensure that 
tampering of account/authentication/certificate- 
based alias detection data is detectable. 

At a later time, any entity may verify that the 
account certificate 130 was, indeed, signed by the 
registrar 110 by decrypting the digital signature 
using the registrar's 110 public key (which is 
known throughout the system) and comparing the 
results with an associated plaintext certificate of the 
decrypted digital signature. The plaintext certificate 
is a decrypted version of the digital signature. If 
they are identical, the entity using the account 
certificate is confident that neither the plaintext nor 
encrypted versions of the account certificate were 
modified after they were created or modified by the 
registrar 110, and that the account certificate data 
did originate from the registrar's workstation. 



When an individual user logs on to a work- 
station, the individual user provides information 
(such as the user's name) that is used by the local 
operating system to locate and fetch an account 

s certificate from the name service program 19 as 
the first step in authenticating, or confirming the 
identity, of the individual user. The local operating 
system then validates the account certificate's digi- 
tal signature using the registrar's 110 public key. If 

w the account certificate is valid, the public key as- 
signed to that account by the registrar 110 is 
known. The individual user trying to log in then 
presents a digitally signed "login delegation certif- 
icate" to the workstation. A login delegation certif- 

75 icate is what the user sends to the local operating 
system to be authenticated. (Typically, this would 
be done by a smartcard issued to the individual 
user by the registrar 110, containing the individual 
user's personal private key.) The operating system 

20 validates the login delegation certificate by decryp- 
ting it using the public key it obtained from the 
account certificate. If the validation is successful, 
the operating system knows that the public key 
obtained from the account certificate matches the 

25 private key in the possession of the individual user 
trying to log on, and is justified in assigning to that 
individual user any rights or privileges associated 
with the account. At no time during the authentica- 
tion process is the CBAD data in the account 

30 certificate used. Since CBAD data does not deter- 
mine the success or failure of a login authentica- 
tion, there is no compromise to the integrity of the 
login authentication system if CBAD data is public. 
In order to invoke a remote application (e.g., from 

35 the application server system 16) to be executed 
on behalf of, or at the request of, a properly 
authenticated local user, the workstation operating 
system generates a so-called remote delegation 
certificate for the request by appending to the 

40 request the individual user's login delegation certif- 
icate and digitally signing it using the workstation's 
private key. A remote delegation certificate is what 
the local computer operating system sends to the 
applications server system 15 to obtain services on 

45 behalf of the individual user. The application server 
system 16 can then verify that the remote delega- 
tion certificate came from the workstation (by ap- 
plying the workstations public key to the signature), 
and, if this is successful, can reauthenticate the 

so identity of the individual user by verifying the 
user's signature on the included remote delegation 
certificate using the user's assigned public key. 
Provided that both of these tests are successful, 
the application server system 16 knows that the 

55 included request emanated from the workstation 
claimed, acting on behalf of the user account 
claimed, and/or use this information to determine 
whether or not the request should be honored. 
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Since CBAD data is not used to determine the 
validity of a remote delegation certificate, there is 
no compromise to the remote request authentica- 
tion system if CBAD data is public. 

Each user also has an associated account cer- 
tificate 130. A user certificate 130 is a data struc- 
ture, generated by the operating system, that in- 
cludes user information 120 and CBAD data, if it 
exists , which are bound together. The binding of 
these data can be provided by using a crypto- 
graphic checksum. The checksum ensures that any 
corruption of the user information 120 is detectable 
by the system. The encryption uses the registrar's 
1 1 0 private key or encryption code, thus generating 
a digital signature that uniquely identifies the 
source of the account information as the registrar 
110. The account certificate 130 is then posted by 
the operating system to the name service system 
135. Thus, execution of selected tasks can be 
restricted to selected users or groups of users. 

During user logon the computer system 10 
collects user certificate information 130, as men- 
tioned above to produce a validation credential for 
the particular user. Such validation credentials are 
used by the computer system 10 to identify each 
user and to determine whether the identified user 
has the necessary privileges to execute a particular 
application. At this juncture the computer system 
10 is using the account certificate information 130 
to produce a validation credential if the particular 
user has been authorized to execute the particular 
identified transaction. Thus, to produce validation 
credentials, to determine which users may access 
certain computer applications, individual ac- 
count/authentication/certificate-based alias detec- 
tion data is collected by the registrar 110. Such 
information includes both the conventional user in- 
formation such as the user's name, mentioned 
above, authentication data assigned to, or obtained 
from, the user, and digitized canonical biometric 
data (BioM), here referred to as Certificate-Based 
Alias Detection Data (CBAD), as mentioned above. 
The system may include accounts which include 
CBAD data and accounts which do not include 
CBAD data. The effect of the presence or absence 
of CBAD data will be described below. 

Although an alias detection system to be de- 
scribed below is here discussed in the context of a 
single computer system, it should be understood 
that this alias detection can be implemented on a 
multi-computer system joined together via large 
computer networks, such as wide area networks. 
This allows computer users located throughout the 
large computer network to execute a common ap- 
plication. 

As illustrated in Figure 2, the CBAD data is 
captured as part of the account operation and 
stored for later use when a separation of duties 



policy needs to be enforced (as will be fully de- 
scribed below). Here, it is used for determining 
user distinctness and detecting alias accounts. This 
use permits the enforcement of a separation of 

5 duties policy that is resistant to attacks by unscru- 
pulous users who assume multiple everyday iden- 
tities. It also allows for enforcement of separation of 
duties policy even with systems using lax admin- 
istration that do not minimize the number of ac- 

10 counts granted to an individual user. It also facili- 
tates creating separate accounts for individuals for 
specialized purposes. Such approaches resist privi- 
lege accumulation, since users log in only with 
specific sets of privileges, rather than with the 

15 accumulated total of all possible privileges which 
they are permitted to exercise. 

Referring now to Figure 3, the steps involved in 
certificate-based alias detection which is invoked 
when a particular unit of processing executes on 

20 behalf of more than one user are shown. Certificate 
based alias detection is provided in the operating 
platform (e.g., operating system, transaction moni- 
tor) of the computer system 10 in Figure 1. 

The computer system 10 produces a validation 

25 credential for the associated user from the account 
certificate. As previously mentioned, a validation 
credential is an integrity-sealed (i.e., digitally 
signed) packet that logically bound together the 
identity of an authenticated user, a request made 

30 on behalf of that user, and the CBAD data, if any, 
for the user. An authenticated user is a user having 
predetermined authorization to execute the particu- 
lar application. The predetermined authorization is 
granted to the user by a system manager or regis- 

35 trar who has the necessary privileges to do so. 
Binding of the integrity-sealed packet is provided 
by the operating system appending the user in- 
formation with the application transaction. Prior to 
executing the unit of processing, however, the se- 

40 curity policy for that unit of processing is exam- 
ined. If necessary to protect security, certificate 
based alias detection is triggered by an appropriate 
statement in the security policy (38 in Figure 4) for 
the specific application transaction which the user 

45 chooses to execute. 

The general manner in which user data and 
alias detection data may be used in a data pro- 
cessing system in the context of the present inven- 
tion will now be explained. It will be assumed that 

50 the transaction to be described, by way of exam- 
ple, requires an application initiation request and an 
application approval entry to be inputted into the 
system by different permitted users. 

As shown in Figure 3, the transaction is ini- 

55 tiated at step 1 58 when an individual user who has 
logged on to the system, and submits a data 
processing application initiation request. A review 
or an approval entry then is submitted at step 158 
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before further processing of the transaction can 
proceed. 

At step 160 the digital signature on the delega- 
tion certificate for the user initiation request and the 
digital signature on the delegation certificate for the 
approval request are first individually validated. If 
this step is successful, the application server sys- 
tem 16 knows that neither certificate has been 
tampered with and knows the assigned public keys 
for the individual user accounts associated with the 
pair of requests, i.e. the account on whose behalf 
the initiation request was made and the account on 
whose behalf the approval request was made. If 
these two public keys are identical, then both re- 
quests were made on behalf of the same account, 
implying that both requests were made on behalf of 
the single user assigned to that account. In this 
event, no further processing of the transaction oc- 
curs and the approval entry is rejected. 

If the identification step results in identification 
of different user accounts, the two sets of account 
credentials are checked for the presence of CBAD 
data at step 162. Checking that the provided CBAD 
data for the request is, indeed exactly the CBAD 
data the registrar 110 captured is implicit in the 
process of the applications server system 16 ob- 
taining and validating the account certificate. The 
CBAD data and the authenticating data are bound 
together into an account certificate by the registrar 
110. 

As previously mentioned, the computer plat- 
form is responsible for validating the account certif- 
icate that is obtained as part of the login before 
proceeding with user authentication. In addition, the 
computer platform, through its operating system, is 
responsible for binding a request to execute a 
transaction to the account certificate and sealing 
this information to provide an integrity-sealed ac- 
count certificates. The computer platform is re- 
sponsible for validating this account certificate be- 
fore using it. A request may fail simply because 
either the authenticated user and/or the authen- 
ticated computer platform are not authorized for a 
particular action. Only if the computer platform 
validates the credential and the request is au- 
thorized for the particular action are CBAD checks, 
if any, made. If either set of account credentials 
does not contain CBAD data, it is assumed at step 
1 63 that both sets of account credentials are asso- 
ciated with the same user and the approval entry is 
rejected and the process terminated. If both sets of 
account credentials contain CBAD data, then the 
digitized biometric data present in each set of 
account credentials are compared at step 164. 

If the compared digitized biometric data are 
within a predetermined range of similarity, the two 
sets of account credentials are presumed at step 
169 to belong to the same user, and the approval 



entry is rejected and the process terminated. A 
range of similarity rather than identicalness be- 
tween the two sets of account credentials is caused 
principally by normal variations and fluctuations in 

5 biometric data received from a given user. Thus 
the range or tolerance permitted in the similarity 
should be narrow enough to prevent overlap be- 
tween truly different users, but should be broad 
enough to encompass normal expected variations 

w in the same user's biometric information. If the two 
sets of account credentials are determined to be 
different at step 168, it is presumed at step 167 
that the application initiation request and the ap- 
proval entry originate from different users and this 

75 comparison result is reported to step 170 for fur- 
ther processing of the transaction. 

If the application initiation request and the ap- 
proval entry request are from different individuals, 
the user initiating the approval entry request is 

20 allowed to approve this application request if au- 
thorized to do so in an access control list asso- 
ciated with the program, described below. 

An example of the present invention will be 
described with reference to a typical computer 

25 based expense reporting and approval procedure 
in an office environment. Any individual is able to 
fill out and submit an expense report. The expense 
report must be approved before it is forwarded to 
disbursements, where a reimbursement check is 

30 prepared. The essential separation of duties re- 
quirement is that no individual can approve his/her 
own expense report. 

Referring again to Figure 1, each individual 
user 1 0a-1 0c is able to execute a personal expense 

35 report application stored in the name service sys- 
tem 18 when logged in under his/her personal 
account. The expense report application displays a 
form at a workstation for the user to fill out. A user 
may then submit an expense report. A submission 

40 transaction causes an expense report to be posted 
to a queue on a queue server system 20 con- 
nected to the local area network 14, where it is 
retained for review. A queue server system 20 is a 
computer system containing various queues, e.g., 

45 print queues, batch queues, etc., that can be ac- 
cessed by any individual computer user 10a-10c 
via the local area network 14. 

One or more selected individuals (10b, for ex- 
ample) are given "management accounts", i.e, 

50 such an individual is authorized to review and ei- 
ther approve or reject expense reports. This is a 
"special account" as mentioned above in connec- 
tion with the previous discussion. A rejection re- 
turns the expense report to the originator, an ap- 

55 proval forwards the report to a pending disburse- 
ments queue located on the queue server system 
20. An individual in disbursements (10c, for exam- 
ple) can then generate a check to clear the ap- 
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proved expense report. The "generate check" 
transaction not only produces the check, but files 
the expense report in an archive and notifies the 
originator that his/her expense report has been 
processed and a check is issued. 

Continuing with Figure 1, individual user 10a on 
workstation 12a initiates via local area network 14 
the expense report application which resides on 
application server system 16. The result is an un- 
approved expense report that is posted by the 
application via the local area network 14 to queue 
server system 20. Subsequently, a second individ- 
ual user 10b on workstation 12b attempts to review 
and approve the expense report on queue server 
system 20 via local area network 14 by executing 
the expense report application on application serv- 
er system 16. The request to approve the expense 
report created/initiated by individual user 10a trig- 
gers the certificate based alias detection method. 
The location and operation of the certificate based 
alias detection is more fully described below. 

Figure 4 illustrates the general data structures 
to support separation of duties using certificate 
based alias detection (CBAD). A name service 
database 30 in name server system 48 contains 
account certificates for individual user accounts 
(33a-c). Each account certificate (33a-c), which has 
been produced as previously described, contains 
relevant information about each individual, includ- 
ing digitally-signed, digitized canonical biometric 
data for the individual; this is referred to as CBAD 
data, fully described with reference to Figure 2. 
The accounts 33a-c also contain the signature of 
the account registry, also described previously. An 
individual's personal and "special" accounts will 
contain the same digitized canonical biometric 
data, i.e., CBAD data, because they represent two 
or more accounts owned by the same individual 
user. Accounts for different individual users will be 
identified by the fact that the CBAD data for each 
of the individual users is distinct. 

Application system programs 35a-d, respec- 
tively, reside in a program library 36 in application 
server system 50. This enables any individual user 
on the local area network 52 access to the program 
library 36. Each type of transaction, such as "cre- 
ate expense report", "submit expense report", "ap- 
prove expense report," etc., has a corresponding 
application system program 35a-c, respectively, re- 
siding in the program library 36 and stored in 
application server system 50. Associated with each 
such transaction program, there is a security poli- 
cy, which states that individuals or groups of in- 
dividuals are able to execute or not execute the 
corresponding transaction. For example, a security 
policy 38 is contained in an access control list 
(ACL) 40a associated with transaction program 35a. 
An ACL is a common mechanism for storing ac- 



cess policies in many computer operating systems. 
The security policy and its trigger is provided as an 
extension to the access policy language. The secu- 
rity policy is added to a particular access policy 

5 storage mechanism of the platform computer sys- 
tem. The access control monitor of the operating 
system platform expresses the access constraint, 
stores the access constraint within the access poli- 
cy, and provides the capability to invoke the appro- 

10 priate method at the time the access policy is 
enforced. How the particular extension is imple- 
mented would be a routine function of the com- 
puter operating system and thus will not be de- 
scribed here. The enforcement or non-enforcement 

15 of separation of duties is defined within the security 
policy 38 for the relevant transaction 35a, for exam- 
ple, i.e., the policy statement 38 indicates that alias 
detection is to be invoked. The security policy 38 
requires that the right to execute ap- 

20 prove_expns_rpt program 35a is to be denied if 
the identity of the originator, or first user, is the 
same as the identity of the second user, i.e., the 
user seeking to approve the expense report in this 
example. This comparison was described previous- 

25 ly in reference to Figure 3. 

Associated with each transaction invocation by 
a user is that user's validation credential (44, 45, 
and 47 in Figure 4), which identifies the user who 
initiated the transaction. A validation credential is 

30 an integrity-sealed unit of processing created by 
the operating system that links a user's account 
certificate, as described in Figure 2, to a requested 
application. Upon transaction invocation, the user's 
validation credential is stored in protected system 

35 memory 46 of Processing Unit X 49 and in name 
service database 30 of name server system 48, 
which contains proof of identity of the user on 
whose behalf a particular unit of processing ex- 
ecutes. In this embodiment of the invention, the 

40 unit of processing is the transaction invocation. The 
association of the individual's validation credential 
with the transaction invocation is a function present 
in the operating system or transaction processing 
monitor which provides the operational platform for 

45 the example application. 

Continuing with the description of Figure 4, a 
first user logs on the name service database 30 
under account UserA. UserA remote validation cre- 
dential 44 (including certificate based alias detec- 

50 tion data) is entered by the operating system in 
protected system memory 46 of Processing Unit X 
49. UserA, wishing to produce an expense report, 
requests execution of a create expns rpt pro- 
gram 35b, which is loaded from application server 

55 system 50. A create_expns_rpt ACL 40b, which 
has previously been created or modified to name 
the account certificate or certificates of the user 
accounts authorized to execute create_expns rpt 
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program 35b, is used to obtain the public keys for 
those accounts, which are then used to validate the 
remote delegation certificate. If the remote certif- 
icate can be validated, the request is then honored, 
causing execution of the create_expns_rpt pro- 
gram 35b by Processing Unit X 49 and an expense 
report file is produced. UserA now attempts to 
execute a submit_expns_rpt program 35c which 
is loaded from application server 50. A sub- 
mit_expns_rpt ACL 40c, which has previously 
been created or modified to indicate the user ac- 
count or accounts authorized to execute sub- 
mit expns_rpt 35c program, is checked against 

UserA remote validation credential 44. 

A match between the UserA validation creden- 
tial 44 and a user's account in the ACL 40c causes 

execution of the submit expns rpt program 35c 

by Processing Unit X 49 which signs the expense 
report file by appending UserA certificate 33a and 
certificate-based alias detection data (to be de- 
scribed more fully below). The expense report file 

is posted to an expense report queue 62 on 

queue server 60. 

Subsequent to these transactions by UserA 
33a, a second user, wishing to review and approve 
the expense report file created by UserA, logs in 
under account UserB. UserB remote delegation 
certificate 45 (including certificate based alias de- 
tection data) is entered by the operating system in 
protected system memory 46 of processing unit X 
49. UserB requests execution of a re- 
view_expns_rpt program 35d, which is loaded 

from application server 50. A review_expns rpt 

ACL 40d, which has previously been created or 
modified to indicate the user account or accounts 
authorized to execute review_expns_rpt program 
35d, is checked against UserB remote validation 
credential 45. A match between the UserB remote 
validation credential 45 and a user's account in the 
ACL 40d causes execution of the re- 
view_expns_rpt program 35d by Processing Unit 
X 49 which produces the expense report file for 
UserB to read/review, for example, on a video 
display device. 

UserB now attempts to execute ap- 
prove_expns_rpt program 35a to approve the ex- 
pense report created by UserA. The digital signa- 
ture on the expense report (which is that of the 
application server system 116) is first validated to 
ensure that no changes have been made to the 
report or to the account certificate associated with 
it. The account certificate (which is signed by the 
registrar) can, but need not be revalidated. It con- 
tains the CBAD data for the user that created the 
report, viz., UserA. The application server system 
1 1 6 now has two validated sets of CBAD data, one 
for UserA and one for UserB. These two sets of 
CBAD data are then compared for similarity. If the 



alias detection check fails, the digitized biometric 
data are regarded as identifying the same user, i.e., 
the application server system 116 must assume 
that UserA and UserB are, in fact, the same individ- 

5 ual (even though the corresponding account certif- 
icates belonged to distinct accounts registered po- 
tentially to different user names). If the certificate- 
based alias detection check indicates that UserA 
and UserB are the same, access to the ap- 

m prove expns rpt program 35a is denied to 

UserB, and a report can be made for notification to 
the system manager or registrar. 

The expense report example has shown how 
the present embodiment satisfies a separation of 

75 duties policy that disallowed one and the same 
unique individual from creating and approving an 
expense report. Rather than insuring that UserA 
and UserB had distinct identities when their user 
accounts were first created, the present embodi- 

20 ment utilized a comparison of certificate based 
alias detection data of each of the users at the 
actual time a request for expense report approval 
was made. Validation of the user's personal in- 
formation only had to be done when the user 

25 account was created initially or modified by the 
system administrator. 

Having described a preferred embodiment of 
the invention, it will now become apparent to one of 
skill in the art that other embodiments incorporating 

30 its concepts may be used. It is felt, therefore, that 
this embodiment should not be limited to the dis- 
closed embodiment, but rather should be limited 
only by the spirit and scope of the appended 
claims. 

Claims 

1. A method of performing alias deiection on a 
computer system, comprising the steps of: 

40 storing in respective user accounts iden- 

tification information uniquely characterizing 
each of a plurality of computer users; 

initiating execution of a computer system 
resource upon a first request from a first user 

45 account, processing a second request for ex- 

ecution using a user account, comparing said 
identification information stored in said user 
account used during said second request with 
said identification information in said first user 

50 account, and determining whether said first 

user account and said user account used in 
said second request are aliases. 

2. A method of operating a distributed computer 
55 system, comprising the steps of: 

storing in respective user accounts iden- 
tification information uniquely characterizing 
each of a plurality of computer users; 
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storing a list of selected user accounts in 
an authorization store; 

initiating execution of a computer system 
resources access program upon request from 
a user account; and s 

processing said request from said user 
account to authorize access to a plurality of 
computer system resources by comparing said 
identification information stored in said user 
account and in said list of selected user ac- ?o 
counts, and determining whether said user ac- 
count is an alias of any of said list of selected 
user accounts. 



of: 

comparing a validation credential linking 
said stored transaction program to user certif- 
icates of accounts authorized to execute se- 
lected transactions of said stored transaction 
program, with a list of authorized user ac- 
counts to determine whether said first user 
account is authorized to execute said first 
stage of said selected transaction program; 
and 

allowing said first user account to initiate 
execution of said first stage only if authorized 
to do so. 



3. A method according to Claim 2, wherein said 
identification information includes authenticat- 
ing information, digitized biometric information, 
and user account information, wherein said 
digitized biometric information is verified by an 
account registrar prior to being stored in a said 
user account for subsequent use. 

4. A method according to Claim 2, wherein said 
step of initiating execution of a computer sys- 
tems access program comprises the steps of: 

comparing a validation credential linking 
said access program to user certificates of 
said selected user accounts in said authoriza- 
tion store to determine whether said user ac- 
count is authorized to execute said access 
program; and 

allowing said user account to initiate ex- 
ecution of said access program if authorized to 
do so. 

5. A method according to Claim 2, wherein during 
said processing step, said request is allowed 
to complete said execution of said access pro- 
gram if said user account is not an alias of 
said list of said selected user accounts, and 
wherein said request is denied to complete 
said access program if said user account is an 
alias of one of said list of selected user ac- 
counts. 

6. A method according to Claim 2, wherein said 
processing step further comprises the step of: 

determining if said user account is the 
same as one of said selected user accounts, or 
if said user account contains no identification 
information, or if said second user's identifica- 
tion information is the same as one of said 
selected user account's identification informa- 
tion, to terminate said request. 

7. A method according to Claim 2, wherein said 
step of initiating execution resides in a stage of 
a transaction program and comprises the steps 



75 8. A distributed computer system, comprising: 

a registry store of respective user ac- 
counts, said accounts containing identification 
information uniquely characterizing each of a 
plurality of computer users; 

20 a stored application transaction program, 

having at least two stages requiring separate 
initiation requests for execution of said stages; 

means, responsive to a first user account 
transaction initiation request, for executing one 

25 stage of said application program; 

means, responsive to a second user ac- 
count transaction initiation request, to execute 
a subsequent stage of said application pro- 
gram; and 

30 means for comparing identification infor- 

mation of said first and second user accounts 
in said store to determine whether said second 
user account is an alias of said first user 
account. 

35 

9. A system according to Claim 8, wherein said 
means responsive to said first request com- 
prises: 

means for extracting from a digitally 
40 signed delegation certificate that associates a 

request with the login delegation certificate of 
the user making the request that delegation 
certificate, and a means of verifying that dele- 
gation certificate against a list of names of 
45 accounts to determine whether the delegation 

certificate was generated on behalf of one of 
the accounts appearing on the list and is there- 
fore authorized to execute said first stage of 
said selected transaction program; and 
so means for allowing said first user account 

to initiate execution of said first stage only if 
authorized to do so. 

10. A system according to Claim 8, including 
55 means to allow said second request to execute 

said subsequent stage of said selected trans- 
action program if said second user account is 
not an alias of said first user account, and to 
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deny said second request to execute said sub- 
sequent stage of said selected transaction pro- 
gram if said second user account is an alias of 
said first user account. 

5 

11. A system according to Claim 8, wherein said 
means for comparing comprises: 

means for terminating said second re- 
quest, said means for terminating comprising: 

means for determining if said first user io 
account is the same as said second user ac- 
count, if said second user account contains no 
identification information, or if said second 
user's identification information is the same as 
said first user's identification information. 75 

12. A distributed computer system for implement- 
ing alias detection, comprising: 

a store of respective user accounts, said 
accounts containing digitally-signed account 20 
certificates including authentication information, 
digitized biometric information, and user ac- 
count information uniquely characterizing each 
of a plurality of computer users; 

a stored application transaction program 25 
having at least two stages requiring separate 
initiation requests for execution of said stages; 

means, responsive to a first user account 
transaction initiation request, for executing one 
stage of said at least one application program; 30 
and 

means, responsive to a second user ac- 
count transaction initiation request to execute a 
subsequent stage of said at least one program, 
for comparing said authentication information 35 
and said digitized biometric information con- 
tained in said user certificate of said first and 
second user accounts in said store; and 

means for allowing execution of said sub- 
sequent stage of said at least one program 40 
only if said second user account is not an alias 
of said first user account. 
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